In a network that employs remote procedure call (RPC) mechanisms, these mechanisms typically use a sequenced message delivery transport (e.g., TCP/IP) to send command and response messages. When a command message is sent to an application by a client, the message arrives at the server and pends in the transport receive queue until the application can receive it. At that point, if the application does not have the necessary resources to complete the requested operation, the command message will languish in the application, consuming receive resources until the remaining resources become available. If no additional receive resources are available that are needed to complete operations already in progress, and the operations already in progress are using all the remaining resources necessary to start the new operation, a deadlock condition exists and no more operations are ever completed.
Existing implementations must insure that sufficient resources are available that this resource starvation situation never occurs. This is typically done by dividing the server resources needed to complete commands equally among the connected clients and extending that number of command credits to each client. Clients then limit their number of outstanding commands to their number of command credits. This method is often called pessimistic flow control.
Pessimistic flow control works well when a server has a small number of clients or when the rate of command arrival is similar among all clients. However, when a server has a large number of clients and the rate of command arrival varies greatly among clients, then server resource limitations lead to poor network performance because no client is able to keep as many commands outstanding as it needs.